NestJS ships a built-in global exception filter that catches every unhandled exception automatically. For HttpException it serializes the response body and sends the correct HTTP status. For any other exception type it returns a generic 500 Internal Server Error response, hiding implementation details from the client.

Built-in exception layer behavior

Built-in exception layer key facts:

1
Always active — runs even without any custom filter configuration.
2
HttpException — serializes the response body from getResponse() with the correct status code.
3
Non-HttpException — returns a generic 500 response, never exposing internal error details.
4
Custom filters extend or override this behavior but never fully remove it.
5
The built-in layer acts as the final safety net behind all custom filters.

Difficulty: 3/10

Topics: exception handling, global filters, NestJS core

Scenario Questions

0-2 years experience

1
You have a simple GET endpoint that throws a new Error('oops'). What does the client receive if you haven't added any custom exception filter?
2
If a controller method throws a NestJS HttpException with status 404, what shape of response does the built‑in global layer send back?
3
When an exception propagates out of a service call and you haven't caught it, how does NestJS handle the response automatically?

2-5 years experience

1
Your API is returning generic 500 responses even for validation errors. Explain why this is happening in terms of the default global exception layer.
2
During debugging you added console logs in a service, but the client still sees a generic error. How would you confirm that the built‑in exception handler is formatting the response?
3
If you need to change the error payload format without writing a full filter, what options does Nest provide given the default behavior?

5-8 years experience

1
In a microservice setup you need to propagate richer error details across services. What limitations does the built‑in global exception layer have, and how would you extend it without breaking existing clients?
2
At high traffic you notice stack traces being logged for every error, hurting performance. How would you adjust the default global exception handling to reduce overhead while keeping useful diagnostics?
3
You must integrate a third‑party monitoring tool that expects a specific error payload. How would you intercept the built‑in exception flow to inject that payload globally?

8+ years experience

1
Your organization is migrating legacy Express error handling into NestJS. How would you plan the transition considering the built‑in global exception layer to ensure backward compatibility across many teams?
2
When designing a shared library for error handling used by dozens of NestJS services, what architectural decisions would you make about extending or replacing the default global exception layer?
3
Discuss the trade‑offs of disabling Nest's default exception layer in favor of a custom global filter in a large, multi‑tenant SaaS platform.

Follow-up Questions

❓Can you describe the internal steps NestJS takes from the moment an exception is thrown to the response being sent?
❓How would you verify in a test that the default global exception handling is active?
❓What are the trade‑offs of relying on this default behavior versus implementing a custom exception filter?